ETSITS122 142V10.0.0 



(2011-05) 



Technical Specification 



Digital cellular telecommunications system (Phase 2+); 

Universal Mobile Telecommunications System (UMTS); 

Value Added Services (VAS) for Short Message Service (SMS) 

requirements 
(3GPP TS 22.142 version 10.0.0 Release 10) 



3^^ 



GLOBAL SYSTEM FOR 
MOBILE COMMUNICATIONS 




3GPP TS 22.1 42 version 1 0.0.0 Release 1 1 ETSI TS 1 22 1 42 V1 0.0.0 (201 1 -05) 



Reference 



RTS/TSGS-0122142va00 
Keywords 



GSM, UMTS 



ETSI 

650 Route des Lucioles 
F-06921 Sophia Antipolis Cedex - FRANCE 

Tel. : +33 4 92 94 42 00 Fax: +33 4 93 65 47 1 6 

Siret N ° 348 623 562 0001 7 - NAF 742 C 
Association a but non lucratif enregistree a la 
Sous-Prefecture de Grasse (06) N° 7803/88 



Important notice 



Individual copies of the present document can be downloaded from: 
http://www.etsi.orq 

The present document may be made available in more than one electronic version or in print. In any case of existing or 

perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). 

In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive 

within ETSI Secretariat. 

Users of the present document should be aware that the document may be subject to revision or change of status. 

Information on the current status of this and other ETSI documents is available at 

http://portal.etsi.orq/tb/status/status.asp 

If you find errors in the present document, please send your comment to one of the following services: 

http://portal.etsi.orq/chaircor/ETSI support.asp 

Copyright Notification 

No part may be reproduced except as authorized by written permission. 
The copyright and the foregoing restriction extend to reproduction in all media. 

© European Telecommunications Standards Institute 201 1 . 
All rights reserved. 

DECT™, PLUGTESTS™, UMTS™, TIPHON™, the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered 

for the benefit of its Members. 
3GPP™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. 

LTE™ is a Trade Mark of ETSI currently being registered 

for the benefit of its Members and of the 3GPP Organizational Partners. 

GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association. 



ETSI 



3GPP TS 22.1 42 version 1 0.0.0 Release 1 2 ETSI TS 1 22 1 42 V1 0.0.0 (201 1 -05) 



Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 
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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document specifies the service requirements associated with series of value-added features for short 
message service (SMS). Specifically, the objective of this document is to specify potential new value-added services for 
SMS in 3GPP that need to be standardized. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TR 21.905: "Vocabulaiy for 3GPP Specifications". 

[2] 3GPP TS 23.040: "Technical reahzation of the Short Message Service (SMS)". 

[3] ITU-T E.164 (1997): "The International f^iblic Telecommunications Numbering Plan". 

[4] IETF STD 001 1 (RFC 2822): "Internet Message Format", URL: 

http://www.ietf.org/rfc/rfc2822.txt . 

[5] 3GPP TS 23.204: " Support of Short Message Service (SMS) over Generic 3GPP Internet Protocol 

(IP) Access. Stage 2". 

[6] 3GPP TR 22.942: "Study on Value Added Services (VAS) for Short Message Service (SMS)". 



3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in [1] and the following apply: 

Short Message Forwarding: The service permits the network to send all incoming short messages addressed to the 
called mobile subscriber's directory number to another directory number. 

Short Message Fihering: The service permits the network to filter certain short messages on behalf of a called/calling 
party based on the called/calling party's preferences. 

Short Message Receipt: The service permits the network to send one or more receipts to inform a calling party the 
status of sent message. 

Short Message Network Storage: The service permits the network to help the subscriber store messages that the 
subscriber has sent or received. 

SMS VPN service: Enables the exchange of SMS messages between VPN (Virtual Private Network) members by using 
a short number, usually similar to the receiver fixed extension number, instead of using the full mobile number of the 
recipient. 
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SMS Auto Reply: The SMS Auto Reply service enables the subscriber to activate an automatic SMS reply in response 
to incoming SMS messages, both from in network subscribers as well as from foreign networks subscribers (incoming 
MT messages from foreign networks). 

SMS Personal Signature: The service allows the end user to personalize its outgoing messages either with a personal 
remark or a business title. The service enables a user to pre-defme a text that will automatically be added to all outgoing 
SMS messages. 

SMS Deferred Delivery: The SMS deferred delivery service provides a subscriber the capability to control the actual 
delivery time of messages created by him. User using this capability can send a message and configure it to be delivered 
at a later time. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply in addition to [1]: 

SMS-SC Short Message Service - Service Centre 

SM Short Message 

VAS-SMS Value-added Services for SMS 



Requirements 



4.1 High Level Requirements 

The VAS-SMS shall be implemented without influencing the existing SMS service. 

The VAS-SMS shall be implemented without depending on the terminal's capability. 

Users shall be able to register, activate, deactivate, withdraw and reconfigure VAS-SMS via the UE, or web portals. 

The VAS-SMS shall be designed and implemented in a way to provide users who joined the services one coherent and 
identical user experience, regardless of the SM flow and SM scenario (e.g. messages to and from applications, MO-MT 
in an in network and MT from Foreign Network). 

Provisioning of VAS-SMS by one operator should not depend on the support of other operators i.e. originating or 
terminating VAS-SMS services should be independently. 

4.2 Overall Service Requirements 
4.2.1 IVIanagement of Service Information 

4.2.1 .1 Capabilities provided to the user 

The VAS-SMS shall be able to support a request from an application to query/change the choice of services for a 
subscriber. 

The VAS-SMS shall be able to support a request from an application to query/change the subscriber's preferences for a 
certain service, for example: 

i) To add or delete or modify a subscriber's filtering conditions by which VAS-SMS can refuse some of the 
subscriber's incoming messages. 

ii) To modify a subscriber's signature that will be appended to an SM sent from the subscriber. 

iii) To modify a subscriber's forwarding address that substitutes for the subscriber's original receiving address. 
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4.2.1 .2 Capabilities provided to the network 

The V AS -SMS shall be able to support a request to query/change the subscriber's information, for example: 

i) To get the detail information about the subscriber's service. 

ii) To add or delete a subscriber's service information. 
The V AS -SMS shall be able to support a request to query the handling results of the subscription service. 

4.2.1 .3 Capabilities provided to authorized third party 

The V AS -SMS shall be able to support a request from an application to modify the contents that will be appended to an 
SM, for example: 

i) to load or unload a particular content provided by the third party 

ii) to associate a content with a particular subscriber or a type of subscribers 

iii) to define the trigger for inclusion or change of such content 

Note: The management of VAS4SMS service is out of scope of 3GPP standardisation. 

4.2.2 Short Message processing 

The VAS-SMS should be able to deal with the content of an SM, for example: 

i) To insert content (as agreed with the subscriber, or as agreed with a third party and authorized by the subscriber) 
into the original SM and form a new SM (e.g. append the signature to the SM, append the content as provided by 
the third party, ...). 

ii) To compile an SM by containing operator's information (e.g. construct a delivery report). 

iii) To use certain words in an SM as the filtering criteria. 

The VAS-SMS should be able to convert the format of an SM into other formats (e.g. email, WAP message, etc). 

4.2.3 Short Message Forwarding 

It shall be supported that users can set certain conditions (e.g., different time periods) for message forwarding. There are 
no significant delays to any part of the service. 

With the advent of SM forwarding there is also the issue of how to handle the situation when a user by mistake sets 
forwarding to wrong number (a number that is in use). Ideally a recipient should be capable of stopping the delivery of 
such SM to its own address. As a minimum the recipient's operator should be capable of identifying forwarded SM and 
stop delivery. Infinite forwarding loops needs to be prevented and the maximum number of times the SM is forwarded 
should be limited. 

SM Forwarding service should support forwarding to numbers of both the operator as well as other operators. 

It shall be possible to Notify a recipient upon activation of the service and only upon his approval activate the service 
for the user. 

There may be no relation between SM Forwarding service and Voice Call Forwarding service. 

4.2.4 Short Message Forwarding multiple subscriptions 

It may be supported that an operator can set a group of subscriptions for which SM are forwarded to the active/last 
activated subscription of that group, under the condition that the delivery address of the SM is associated to a 
subscription of that group and that address is not registered on the network. 
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4.2.5 Short Message filtering 

It shall be supported that users can set certain conditions for message filtering. 

4.2.6 SInort Message receipt 

It shall be supported that the callee can configure the content of an additional receipt SM for different callers, so the 
standard Status Report may be accompanied by a newly generated SM with the content provided by the operator. 

4.2.7 SInort Message Networl< Storage 

It should be possible for the operator to support Short Message Network Storage to allow users to store the messages in 
the network. 

It should be possible for users to store the messages in the network based on their personal settings (e.g. store all sent & 
received messages, store the messages from/to particular users, store the messages sent & received in a specified period 
of time etc). 

It should be possible for users to store and manage the messages for their preference (e.g. users can set different folders 
to store different sort of messages, therefore it is convenient to inquire the stored messages based on message sort or 
key words). 

It should be possible for the operator to ensure all relevant information of the messages stored in the network are 
consistent with that displayed to users, e.g. content of the messages, sender/recipient, sending/receiving time, etc. 

It shall be supported that user can pre-set certain conditions for storage. The storage condition includes all sent 
messages, all received messages, messages sent to or received from one or more special phone numbers and so on. 

It should be possible for the operator to prevent storage of configuration SM, notifications (e.g. voice mail, SM delivery 
notifications). 

It shall be supported that users can transfer the messages stored in the message depository to any other mobile phone. 

It shall be supported that users can inquire the messages stored in the message depository according to certain query 
conditions (e.g., short message receiver, short message sender, key words etc.). 

It shall be supported that users can manage the stored messages via a website, and it shall be possible for the user to set 
access right for other users ( e.g. read only , read and download etc), in this way, other users are able to inquire his 
stored messages through a link to the website after valid authentication. 

In case of multiple delivery attempts SM will be copied only once regardless of the number of delivery attempts. 

It shall be possible to combine concatenated SM to single Message in the Network store or alternatively indicate in the 
message that it is part of concatenated SM. 

The Short Message Network Storage service shall prevent duplicate storage message as a result of failure in 
transmission of the original SM. 

Messages should be stored in the Network Storage regardless of the user availability and as soon as the original SM is 
being processed in the SMSC. 

4.2.8 SInort Message to multiple destinations 

It shall be able to support inclusion of multiple recipients in a message when a user sends a single message to multiple 
individuals. 

It should be possible for all recipients of the message to be aware of other recipients. 

It should be possible for a recipient to choose to whom the reply message is sent, i.e. to the original sender and to other 
recipients of the original message. 

It shall be supported that a user can include multiple destination addresses in a message. The recipient except those 
addresses displaying information is blocked shall receive information on all recipients of the message. 
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It shall be supported that each recipient of the message can send a message back to all recipients of the original 

message. 

4.2.9 Short Message Virtual Private Network (VPN) 

Sending messages to local numbers based on the dialling plan should be supported. There shall be no significant delays 
to any part of the service. 

4.2.1 Sinort Message Auto Reply 

It shall be possible that users can activate the SM Auto Reply Service to be active for different time periods. In addition 
it shall be possible to configure the system to reply only once to each sender in a predefined period of time. 

It shall be possible for users to configure and manage their Automatic Reply messages, e.g. edit and delete the content 
of the message. 

It shall be possible for users to set different Automatic Reply messages to different senders. 

Auto reply to auto reply loops need to be prevented. 

4.2.1 1 Short Message Personal Signature 

The SM Personal Signature Service shall support certain conditions configured by users or control system wide (e.g., 
append personal signature depending on the original short message length, append personal signature to certain 
destinations). There shall be no significant delays to any part of the service. 

4.2.12 Short Message Deferred Delivery 

The SM Deferred delivery shall support the following delivery time options: 

Relative timing - The text will include information as for the of how many more days, hours, minutes shall pass 
before the message shall be delivered. 

Absolute timing - The text will include information indicating of the specific Date and Time for the message to 
be delivered 

The SM Deferred Delivery Service shall support all type of languages 

The SM Deferred Delivery Service shall support concatenated messages 

There shall be no significant delays to any part of the service. 

4.2.13 Management and control of network based repository 

VAS-SMS should be able to provide following capabilities to support network based repository: 

The VAS-SMS should allow configuring in such a way that certain sent or received messages of a particular user 
can be stored persistently in a network based repository. 

The VAS-SMS should be able to support a request from SMS-SC to persistently store a sent message in a 
network based repository at the time of sending. 

The VAS-SMS should be able to support a request from an application to upload certain messages into a 
network based repository for persistent storage. 

The VAS-SMS should be able to support a request from an application to retrieve/delete certain messages stored 
in a network based repository 

The VAS-SMS should be able to support a request from an application to view the list of messages and related 
attributes (e.g. sender, recipient, date/time, etc) in a network based repository 
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4.2.14 Addressing 

The V AS -SMS should support different addressing formats to identify the sender and recipient; it should support both 
MSISDN[3] and e-mail addressing schemes[4]. 

A short number should be supported. This number should be unique within VPN where it is used. 

The VAS-SMS should support an alpha-numeric addressing format (similar to specified in [2]). 

The VAS-SMS should be able to submit one message to multiple recipients. 

The VAS-SMS should be able to support the request to hide the sender's or other recipients' addresses. 

5 Requirements for service priority and Interaction 

The different rules of VAS-SMS priority and interaction are provided by operator. For example, the priority order 
maybe as following: 

- SM Filtering 

- SM Network Storage 
SM Forwarding 

- etc. 

The VAS-SMS should be classified by priority and triggered according to priority order. 
The VAS-SMS should provide the capability to configure certain priority. 
Caller SMS receipt has higher priority than Callee SMS Receipt service. 

6 Quality of Service 

The quality of basic SMS service should not be affected by introducing the VAS-SMS. 

The following key performance for quality of VAS-SMS shall be kept consistent with basic SMS. For example: 

SMS delivery successful rate 

authentication successful rate 

end to end data loss rate 

end to end data delay 

charging successful rate 

reliability of network and service 



Charging aspects for VAS-SIVIS 



The VAS-SMS shall provide accounting rules for accurate accounting. It shall be able to support following charging 
aspects. 

Charging Model 

The VAS-SMS charging includes basic communication fee and special service fee. 
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Basic communication fee is paid for usage of network resource. CDR is generated by SMSC. Special service fee is paid 
for usage of the VAS-SMS. CDR is generated by the VAS-SMS system. Charging models of special service fee shall 
include but not limit to the following items: 

i) charging per VAS-SMS 

ii) monthly basis 

Per each service category, different charging models and rates should be configurable for the special service fee. 

- Charging principle 

The following principles shall be supported according to different service categories: 

i) VAS-SMS triggered by sending party - basic communication fee and special service fee are paid by the 
sending party. 

ii) VAS-SMS services triggered by recipient - basic communication fee is paid by the sending party, whilst 
special service fee is paid by the recipient. 

iii) Charging only happens after the status report has been received by the SMSC. 

Charging Scheme 

The VAS-SMS shall support a standardized interface to transfer CDRs and other charging related information between 
the VAS-SMS and the billing system for prepaid and post-paid billing solutions. 



8 Security 



Security of the VAS-SMS services shall be consistent with basic SMS service. The user shall be able to use and access 
the VAS-SMS services in a secure manner. 

VAS-SMS should support Lawful Interception as required by Regional Regulations. 



9 Interworking 

Interworking with existing messaging technologies and messaging services should be supported. 
The VAS-SMS should be able to send the content of an SM to a reachable address, for example: 
i) To send an email to email severs after converting the SM into an email. 

ii) To send a WAP message to a WAP Push Gateway after converting the SM into a WAP message, 
iii) To send an SM to a subscriber by sending an SM to SMSC. 

iv) To send an SM via IMS. Refer to [5]. 
v) To send a delivery report . 

10 Roaming 

General roaming requirements should be compliant with roaming function of SMS. 

The user should be able to experience the consistent VAS-SMS services whether in home network or roaming 
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